Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

provider/aws: Support suspending auto scaling group processes #5107

Closed
wants to merge 8 commits into from
Closed

provider/aws: Support suspending auto scaling group processes #5107

wants to merge 8 commits into from

Conversation

tpounds
Copy link
Contributor

@tpounds tpounds commented Feb 12, 2016

Adds support for suspending/resuming auto scaling group processes (e.g. Launch, Terminate, etc.).

see: http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/US_SuspendResume.html

@stack72
Copy link
Contributor

stack72 commented Feb 12, 2016

Hi @tpounds,

I think this needs to change slightly, currently (in other resources), when we have an update command after a create command, the create should call the update command (e.g. resource_aws_instance.go)

func resourceAwsInstanceCreate(d *schema.ResourceData, meta interface{}) error {
    conn := meta.(*AWSClient).ec2conn

    instanceOpts, err := buildAwsInstanceOpts(d, meta)
    if err != nil {
        return err
    }
        ..........

    // Update if we need to
    return resourceAwsInstanceUpdate(d, meta)
}

func resourceAwsInstanceUpdate(d *schema.ResourceData, meta interface{}) error {
    conn := meta.(*AWSClient).ec2conn

}

I think will have to be the pattern in this case as well.

Thoughts?

Paul

@tpounds
Copy link
Contributor Author

tpounds commented Feb 12, 2016

@stack72 I agree creating and then updating is cleaner. I'll ping you once I make the necessary changes to the resource.

@stack72
Copy link
Contributor

stack72 commented Feb 16, 2016

@tpounds any luck with these updates yet? :)

@stack72 stack72 self-assigned this Feb 16, 2016
@tpounds
Copy link
Contributor Author

tpounds commented Feb 16, 2016

@stack72 Sorry I haven't provided an update yet. I took a look and updating the create/update code paths like you described requires consolidation of the auto scaling group wait for capacity logic (see: resource_aws_autoscaling_group.go:225, :380). In addition to that change, special care is required to prevent waiting when the Launch or Terminate policies are suspended since you might wait around forever for the capacity to spin up/down.

My high-level thoughts to fix this are as follows:

  1. Consolidate wait for capacity logic (separate pull request)
  2. Rebase this feature on config: bundle metadata requires global constraints #1 with consideration for Launch/Terminate policies as described above.

Thoughts?

@tpounds
Copy link
Contributor Author

tpounds commented Mar 24, 2016

@stack72 I've created #5824 to cleanup the wait for capacity logic. I'll be rebasing this commit on that shortly.

@tpounds
Copy link
Contributor Author

tpounds commented Mar 27, 2016

@stack72 Feature should be good to go now. I've rebased this change on #5824 so that should probably be merged first.

@sj26
Copy link

sj26 commented Nov 2, 2016

We've love support for this as well. Any reason this PR stagnated? Can I help get it over the line?

@stack72
Copy link
Contributor

stack72 commented Dec 5, 2016

Closed via #10096

@stack72 stack72 closed this Dec 5, 2016
@ghost
Copy link

ghost commented Apr 19, 2020

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked and limited conversation to collaborators Apr 19, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants